Multimedia program recording schedule manager

ABSTRACT

A multimedia program recording schedule manager for DVR systems is described. In a first embodiment, for example, a method implemented by one or more server computing devices, the method comprising: receiving input selecting a particular DVR system; receiving input selecting a particular multimedia program for the particular DVR system to record on a repeat basis; adding the particular multimedia program to a server-side instance of a repeat recording schedule for the particular DVR system; and synchronizing the server-side instance of the repeat recording schedule with another instance of a repeat recording schedule for the particular DVR system resulting in the addition of the particular multimedia program to the other instance of the repeat recording schedule. In one embodiment, the other instance of the repeat recording schedule for the particular DVR system is a data component of the particular DVR system.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.13/223,232, entitled “MULTIMEDIA PROGRAM RECORDING SCHEDULE MANAGER,”filed Aug. 31, 2011. The entire contents of the above mentionedapplication are hereby incorporated by reference for all purposes as iffully set forth herein. The applicant(s) hereby rescind any disclaimerof claim scope in the parent application(s) or the prosecution historythereof and advise the USPTO that the claims in this application may bebroader than any claim in the parent application.

TECHNICAL FIELD

The present invention relates to management of program recordingschedules for Digital Video Recorder (DVR) systems.

BACKGROUND

Today, multimedia content and programming is available from a variety ofdifferent multimedia content providers. For example, today there aremany broadcast television, cable, satellite, and Internet serviceoperators that can provide multimedia programming to consumers in theirhomes and elsewhere. Further, many consumers consume multimediaprogramming from more than one content provider. For example, it isincreasingly common for a consumer to consume multimedia programmingfrom a broadcast television, cable, or satellite content provider inaddition to one or more Internet-based content providers. This consumerpractice of “multi-sourcing” multimedia programming should become moreand more prevalent as the availability of high-bandwidth Internetconnections to the home and mobile computing devices increases.

With the growth in availability of multimedia programming from contentproviders, a consumer can often be in a situation where a program ofinterest is being offered by a content provider at a time that is notconvenient for consumption or at a time that conflicts with the offeringof another program of interest. For example, the season premiere of ahighly anticipated television program may be broadcast by a contentprovider at the same time the content provider is also broadcasting alive sports event. To allow consumers to consume multimedia programmingof interest at times that are most convenient to the consumers, DigitalVideo Recording (DVR) systems have been developed. A DVR system allows auser to record multimedia programs at the time they are offered bycontent providers yet consume the recorded multimedia programs at alater time. For example, the DVR system may allow the user to view thelive sports event while recording the season premiere of the televisionprogram and allow the user to view the season premiere after watchingthe live sports event even though both the live sports event and theseason premiere were broadcast by the content provider at the same time.

Typically, the DVR system itself is located where the user consumesmultimedia content from content providers. For example, the DVR systemmay be a component of the user's in-home television system that receivesmultimedia content via a cable, network, or satellite link. The DVRsystem typically stores recorded multimedia programming in a digitalform to a local storage device component of to the DVR system. Further,the DVR system may provide program recording scheduling capabilitiesthat allow the user to configure the DVR system with a program recordingschedule. For example, the DVR system may be configured to automaticallyrecord a certain television channel for one hour every Friday at 8 μm.The program recording schedule is typically stored and maintainedlocally as a data component of the DVR system. As a result, if an old ordefective DVR system is replaced with a new DVR system, the programrecording schedule on the replaced DVR system may need to bere-configured by the user on the new DVR system. Typically, this meansthat the user is required to duplicate work already performed for thereplaced DVR system. The user may find this duplicative work to betedious and time-consuming.

Another drawback to typical approaches for managing program recordingschedules in DVR systems is that each DVR system may have to beseparately and independently configured by the user with a programrecording schedule. This is inconvenient if the user operates multipleDVR systems. For example, the user may operate one DVR system attachedto a television in the living room and another DVR system attached to atelevision in a bedroom. If the user wants to view a recorded program intwo different locations or from two different DVR systems, copying ormoving the program between DVR systems may not be a viable option. Forexample, it may be a violation of copyright restrictions to copy amultimedia program stored on one DVR system to another DVR system. Asanother example, the DVR system may record multimedia content withDigital Rights Management (DRM) protection which prevents playback ofrecorded multimedia content on any DVR system other than the one thatrecorded the content. Further, the data size of a recorded program mayso large that copying or moving the recorded program from one DVR systemto another, even over a high-bandwidth link, may take a prohibitiveamount of time. One possible solution to this dilemma is for the user toseparately and independently configure each of the multiple DVR systemsto record the desired program. However, as noted above, the user mayfind this duplicative work to be tedious and time-consuming.

Given the drawbacks of typical approaches for managing program recordingschedules in DVR systems, an improved technique is needed.

BRIEF DESCRIPTION OF DRAWINGS

The present invention is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings and in whichlike reference numerals refer to similar elements and in which:

FIG. 1 is a block diagram and schematic illustration of a programrecording schedule management system, according to a possible embodimentof the invention;

FIG. 2 is a block diagram and schematic illustration of the componentsof a DVR system, according to a possible embodiment of the invention;

FIG. 3 is a flowchart illustrating steps of a DVR system registrationprocess, according to a possible embodiment of the invention.

FIG. 4 is a block diagram and schematic illustration of an electronicprogram guide, according to a possible embodiment of the invention.

FIG. 5 is a flowchart illustrating steps for creating a repeat recordingschedule for a DVR system, according to a possible embodiment of theinvention.

FIG. 6 is a flowchart illustrating steps for creating a repeat recordingschedule for a DVR system based on an another repeat recording schedulecreated for another DVR system, according to a possible embodiment ofthe invention.

FIGS. 7A and 7B depict a user interface for creating a repeat recordingschedule for a DVR system based on another repeat recording schedulecreated for another DVR system, according to a possible embodiment ofthe invention.

FIG. 8 is a flowchart illustrating steps for preventing a concurrentrecording conflict, according to a possible embodiment of the invention.

FIG. 9 is a block diagram and schematic illustration of a computersystem on which a possible embodiment of the invention may beimplemented.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be apparent, however,that the present invention may be practiced without these specificdetails. In other instances, well-known structures and devices are shownin block diagram form in order to avoid unnecessarily obscuring thepresent invention.

Several features are described hereafter that can each be usedindependently of one another or with any combination of the otherfeatures. However, any individual feature might not address any of theproblems discussed above or might only address one of the problemsdiscussed above. Some of the problems discussed above might not be fullyaddressed by any of the features described herein. Although headings areprovided, information related to a particular heading, but not found inthe section having that heading, may also be found elsewhere in thespecification.

Example features are described according to the following outline:

-   -   1.0 OVERVIEW    -   2.0 REPEAT RECORDING SCHEDULE MANAGEMENT SYSTEM—FUNCTIONAL        OVERVIEW    -   3.0 REPEAT RECORDING SCHEDULE MANAGEMENT SYSTEM—SYSTEM OVERVIEW    -   4.0 EXAMPLE DVR SYSTEM    -   5.0 EXAMPLE DVR SYSTEM REGISTRATION    -   6.0 EXAMPLE PROGRAM GUIDE    -   7.0 EXAMPLE OF CREATING A REPEAT RECORDING SCHEDULE    -   8.0 EXAMPLE OF CREATING A REPEAT RECORDING SCHEDULE FOR A DVR        SYSTEM BASED ON ANOTHER REPEAT RECORDING SCHEDULE FOR ANOTHER        DVR SYSTEM    -   9.0 EXAMPLE OF PREVENTING CONCURRENT RECORDING CONFLICTS    -   10.0 EXAMPLE COMPUTING DEVICE    -   11.0 EXTENSIONS AND ALTERNATIVES

1.0 OVERVIEW

A multimedia program recording schedule manager for DVR systems isdescribed. In a first possible embodiment, for example, a methodimplemented by one or more server computing devices, the methodcomprising: receiving input selecting a particular DVR system; receivinginput selecting a particular multimedia program for the particular DVRsystem to record on a repeat basis; adding the particular multimediaprogram to a server-side instance of a repeat recording schedule for theparticular DVR system; and synchronizing the server-side instance of therepeat recording schedule with another instance of a repeat recordingschedule for the particular DVR system resulting in the addition of theparticular multimedia program to the other instance of the repeatrecording schedule; wherein the other instance of the repeat recordingschedule for the particular DVR system is a data component of theparticular DVR system.

In one aspect of the first possible embodiment, after the synchronizing,the server-side instance of the repeat recording schedule comprises anordered listing of multimedia program identifiers and associated channelidentifiers and the other instance of the repeat recording schedulecomprises the same ordered listing of multimedia program identifiers andassociated channel identifiers.

In another aspect of the first possible embodiment, in response toreceiving search criteria, searching a program guide associated with theDVR system to identify one or more multimedia programs including theparticular multimedia program that satisfy the search criteria.

In yet another aspect of the first possible embodiment, the otherinstance of the repeat recording schedule for the particular DVR systemis stored on a non-volatile storage medium of the particular DVR system.

In still yet another aspect of the first possible embodiment,synchronizing the server-side instance of the repeat recording schedulewith the other instance of the repeat recording schedule comprisesestablishing a network connection with the particular DVR system andsending data representing the particular multimedia program to theparticular DVR system over the network connection.

In still yet another aspect of the first possible embodiment, thenetwork connection is a Transmission Control Protocol (TCP) connection.

In still yet another aspect of the first possible embodiment, receivingand storing data reflecting a concurrent recording capability of theparticular DVR system.

In a second possible embodiment, a method implemented by one or moreserver computing devices, the method comprising: receiving inputselecting a source DVR system associated with a user; receiving inputselecting a target DVR system associated with the user; causingpresentation of a user interface to the user, the user interfacecomprising a set of one or more selectable items, each selectable itemof the set of selectable items corresponding to a repeat recording itemof a repeat recording schedule for the source DVR system, each repeatrecording item of the repeat recording schedule for the source DVRsystem comprising an identifier of a multimedia program; receiving inputindicating selection of a particular selectable item of the set ofselectable items; identifying a particular multimedia program from oneor more program guides associated with the target DVR system based onthe identifier of the multimedia program of the repeat recording itemcorresponding to the particular selectable item; adding the particularmultimedia program to a server-side instance of a repeat recordingschedule for the target DVR system.

In an aspect of the second possible embodiment, synchronizing theserver-side instance of the repeat recording schedule with anotherinstance of a repeat recording schedule for the target DVR systemresulting in the addition of the particular multimedia program to theother instance of the repeat recording schedule; wherein the otherinstance of the repeat recording schedule for the target DVR system is adata component of the target DVR system.

In a third possible embodiment, a method implemented by one or moreserver computing devices, the method comprising: receiving and storingdata reflecting a concurrent recording capability of a target DVR systemassociated with a user; receiving input selecting a source DVR systemassociated with the user; receiving input selecting the target DVRsystem; causing presentation of a user interface to the user, the userinterface comprising a set of one or more selectable items, eachselectable item of the set of selectable items corresponding to a repeatrecording item of a repeat recording schedule for the source DVR system,each repeat recording item of the repeat recording schedule for thesource DVR system comprising an identifier of a multimedia program;receiving input indicating selection of a particular selectable item ofthe set of selectable items; identifying a particular multimedia programfrom one or more program guides associated with the target DVR systembased on the identifier of the multimedia program of the repeatrecording item corresponding to the particular selectable item; inresponse to determining, based on the data reflecting the concurrentrecording capability of the target DVR system, that adding theparticular multimedia program to a repeat recording schedule for thetarget DVR system would cause a concurrent recording conflict, causingnotification to the user of the concurrent recording conflict.

In an aspect of the third possible embodiment, determining, based on thedata reflecting the concurrent recording capability of the target DVRsystem, that adding the particular multimedia program to a repeatrecording schedule for the target DVR system would cause a concurrentrecording conflict includes determining, from the one or more programguides associated with the target DVR system, any overlap betweenepisodes of multimedia programs concurrently listed in the repeatrecording schedule and episodes of the particular multimedia program.

Other possible embodiments include, without limitation, a non-transitorycomputer-readable medium that includes processor-executable instructionsthat enable a processing unit to implement one or more aspects of thedisclosed methods as well as a system configured to implement one ormore aspects of the disclosed methods.

2.0 REPEAT RECORDING SCHEDULE MANAGEMENT SYSTEM—FUNCTIONAL OVERVIEW

Historically, service providers that provide data to DVR systems over adata network typically only provide program guide data and updates forsoftware executed on the DVR systems. This program guide data typicallycomprises information organizing multimedia programs offered by contentproviders in a daily, weekly, season-long, or other time-periodschedule. Generally, the program guide comprises a listing of multimediaprograms offered by content providers, the channels on which theprograms are offered, and the times the programs are offered on thechannels. For example, the program guide data might be a set oftelevision listings or an interactive or non-interactive electronicprogram guide.

With this program guide data, a DVR system can be configured by a userto record multimedia programs according to the information provided inthe program guide. For example, the user might interact with aninterface of the DVR system to select a particular program to record.

Further, with this program guide data, the DVR system can be configuredby the user to record selected programs autonomously from the serviceprovider. In other words, once the program guide data has been obtainedby the DVR system, the user can schedule the DVR system to recordprograms of interest without the DVR system having to communicate withthe service provider. When configured in this way, data representing therecording schedule is stored locally as a data component of the DVRsystem. For example, the DVR system may comprise a hard disk or otherdata storage medium for storing the recording schedule data.

Thus, historical approaches for managing programming recording schedulesfor DVR systems typically involve the DVR systems obtaining a programguide from a service provider and thereafter operating autonomously fromthe service provider and other DVR systems. In particular, in thehistorical approaches, program recording schedule configuration istightly coupled to the DVR system it configures. Thus, if the configuredDVR system is decommissioned or replaced, the program recording scheduleconfiguration is lost. Further, there is no effort with the historicalapproaches to leverage the program recording schedule configuration ofone DVR system when configuring another DVR system. Finally, thehistorical approaches do not provide tools to the user for managingmultiple DVR systems as a cluster such that one DVR system in thecluster can assume recording workload that cannot be handled by anotherDVR system in the cluster.

In contrast to historical approaches, a possible embodiment incorporatesa program recording schedule management system that allows users to moreeasily and efficiently configure their DVR systems with repeat recordingschedules. A repeat recording schedule is a recording schedule thatspecifies multimedia program series (e.g., video, audio, etc.) and thecontent provider channels, URLs, etc., the program series are offered onsuch that a DVR system, when configured with the repeat recordingschedule, will record some or all instances (i.e., episodes) of themultimedia program series on the channels, URLs, etc., in accordancewith the repeat recording schedule.

With this system, it is possible for a user to configure a DVR systemwith a repeat recording schedule without having to recreate the repeatrecording schedule from scratch. For example, if the user replaces anold or damaged DVR system with a new DVR system, the repeat recordingschedule on the replaced DVR system can be configured on the new DVRsystem without the user having to recreate the repeat recording scheduleon the new DVR system by repeating all of the configuration steps takenwhen the schedule was originally created on the replaced DVR system.

It is also possible with the system for the user to create repeatrecording schedules for multiple DVR systems without having to configureeach of the multiple DVR systems separately and independently. Instead,the user can leverage a repeat recording schedule created for one of themultiple DVR systems when creating a repeat recording schedule foranother of the multiple DVR systems.

The system may also include a scheduling component for automaticallyscheduling programs of interest for recording amongst a user's multipleDVR systems. The scheduling component can intelligently determine whichof the user's multiple DVR systems is best suited to record a givenprogram of interest on a repeating basis based upon resource capabilityand availability of the multiple DVR systems. As one example, if aparticular DVR system selected by the user to record a program series ofinterest on a repeating basis is low on available local storage spacefor storing recorded programs, the scheduling component may suggest adifferent one of the user's DVR systems that is not low on availablelocal storage space for recording the program series on a repeatingbasis. As another example, if scheduling a particular DVR system torecord a program series of interest on a repeating basis would cause theparticular DVR system to exceed its concurrent recording capabilities,the scheduling component may suggest a different one of the user's DVRsystems that would not be overscheduled.

An approach of a possible embodiment is to store and manage DVR systemrepeat recording schedules at a location remote from the DVR systemsthemselves. At the remote location is a program recording schedulemanager. The schedule manager may be hosted by a server or multipleservers. The schedule manager is connected to the DVR systems via a datanetwork (e.g., the Internet, an intranet, local network, satellitenetwork, microwave network, cable network, wireless network, telephoneline, etc.). The schedule manager provides a user interface for users toconfigure repeat recording schedules for their DVR systems. The schedulemanager configures the users' remote DVR systems over the data networkin accordance with locally maintained and stored repeat recordingschedules.

By storing and managing repeat recording schedules for DVR systems at anetwork location remote from the DVR systems themselves, DVR systems canbe decommissioned and replaced without losing all repeat recordingschedule configurations for those DVR systems. Further, a user canconfigure and reconfigure a DVR system with a repeat recording schedulewithout having to create a schedule from the ground up, saving time andincreasing enjoyment of the DVR system.

In addition, by connecting multiple DVR systems to the schedule manager,the schedule manager can be provided a “view” of all of a user's DVRsystems including their resource capabilities, resource availabilities,and repeat recording schedule configurations via, for example, a webinterface accessible by the user's web browser.

In some cases, the user can configure a DVR system with a repeatrecording schedule by leveraging an existing repeat recording scheduleconfiguration. In one possible embodiment, the lifecycle of a repeatrecording schedule configuration is independent of the lifecycle of theDVR system(s) configured according to that schedule, thereby allowingthe user to decommission, replace, or upgrade DVR system(s) withoutlosing a repeat recording schedule configuration or having to recreate arepeat recording schedule configuration from scratch.

In addition, a new DVR system can be configured with a repeat recordingschedule based on an existing repeat recording schedule configuration,perhaps even for another DVR system, without having to create a scheduleconfiguration for the new DVR system from the ground up.

In accordance with certain possible embodiments of the presentinvention, the schedule manager system collects resource capability andavailability information about a user's multiple DVR systems. Suchcollected information allows the schedule manager system to aid the userin making informed decisions and how best to schedule programs forrecording on a repeat basis amongst the user's multiple DVR systems.

Thus, according to possible embodiments, multimedia program recordingschedule management systems are disclosed that include, for example,building blocks such as: server computer hardware for hosting andexecuting logic (e.g., software) for performing various repeat recordingschedule management and user interface functions as described herein; adatabase operatively coupled to the server-side logic for storing andretrieving repeat recording schedule data, program guides, resourcecapability data, and resource availability data for remote DVR systems;and a network interface for operatively coupling the logic to remote DVRsystems over a data network for communicating with remote DVR systemsincluding sending and receiving repeat recording schedule data to andfrom remote DVR systems and receiving resource capability data andresource availability data from remote DVR systems.

It will be understood that these, and other associated building blocksand components, may be configured as stand-alone elements, or may becombined together in one or more assemblies, as needed or appropriatefor the particular implementation at hand.

3.0 REPEAT RECORDING SCHEDULE MANAGEMENT SYSTEM—SYSTEM OVERVIEW

Referring now to FIG. 1, therein is shown a block diagram and schematicillustration of a repeat recording schedule management system 100according to a possible embodiment. The actors in the system 100 includecontent provider(s) 101, user(s) 102, and a service provider 105. Thecontent provider(s) 101 provide multimedia content and programming tothe DVR system(s) 103. User(s) 102 operate the DVR system(s) 103 andpersonal computing device(s) 104 and maintain account(s) 113 with theservice provider 105. The service provider 105, among other functions asdescribed in greater detail herein, receives data and information fromthe DVR system(s) 103 over a data network and provides data andinformation to the DVR system(s) 103 over the data network. The serviceprovider 105 may provide data and information to the DVR system(s) 103on a subscription basis for a fee paid by the users(s) 102 to theservice provider 105.

While in FIG. 1 the service provider 105 is shown separately from thecontent provider(s) 101, it should be understood that a content provider101 and the service provider 105 may be one and the same and there is norequirement that the service provider 105 be under control of amanagement entity separate from the content provider(s) 101.

The service provider 105 operates one or more server(s) 106 comprisingschedule management logic 107, user interface logic 108, and a database109. In a possible embodiment, the schedule management logic 107 and theuser interface logic 108 are implemented in server software operating inan Internet-connected environment running under an operating system,such as the Microsoft Windows operating system. However, the logics 107and 108 are not limited to any one particular application or anyparticular environment. Instead, the logics 107 and 108 may beadvantageously embodied on a variety of different platforms, includingLinux, UNIX, Mac OS, FreeBSD, and the like. Each of the server(s) 106need not comprise all of the schedule management logic 107, the userinterface logic 108, and the database 109. Some of the server(s) 106 maycomprise only some of these components or only portions of one or moreof these components. For example, some of the servers 106 may bededicated to executing the user interface logic 108 while other servers106 may be dedicated to executing the schedule management logic 107.Further, the database 109 may be partitioned across geographicallydispersed servers 106 to improve the locality of reference to database109 data by DVR systems 103 and personal computing devices 104 accordingto the requirements of the implementation at hand.

A server 106 may be implemented on a conventional or general-purposecomputer system, such as the computer system 900 of FIG. 9. For purposesof discussion, the following description will present examples in whichit will be assumed there exist one or more “servers” that communicatewith one or more DVR systems and/or one or more personal computingdevices (“clients”). The system, however, is not limited to anyparticular environment or device configuration. In particular, aclient/server distinction is used to provide a framework for discussion.The system may be implemented in any type of system architecture orprocessing environment capable of supporting the techniques for managingprogram recording schedules as disclosed herein.

The user interface logic 108 is operatively coupled to the DVR system(s)103 and the personal computing device(s) 104 via one or more datanetworks. Through the user interface logic 108, a user 102 can view,create, and update repeat recording schedule(s) 111 for the user's DVRsystem(s) 103. When creating or updating a repeat recording schedule 111for a DVR system 103, the user 102 can search and browse the programguide 112 associated with the DVR systems 103 through the user interfacelogic 108 to select one or more programs to add to the repeat recordingschedule 111 for the DVR system 103. If a user operates more than oneDVR system 103, a user can simultaneously view side-by-side repeatrecording schedules 111 for the user's multiple DVR systems 103. Withthe side-by-side view, the user can select one or more programs from therepeat recording schedule 111 of one of the user's multiple DVR systems103 to be copied or moved to the repeat recording schedule 111 ofanother of the user's other DVR systems 103. These and other userinterface operations performed by user interface logic 108 are describedin greater detail below.

The schedule management logic 107 is operatively coupled to the DVRsystem(s) 103 via one or more data networks (e.g., the Internet, anintranet, local network, satellite network, microwave network, cablenetwork, wireless network, telephone line, etc.). The schedulemanagement logic 107 receives resource capability and availability datafrom the DVR system(s) 103. Received resource capability andavailability data is stored in the database(s) 109 as resourcecapability/availability data 110. Such data 110 may be used by theschedule management logic 107 when determining how to assign a repeatrecording request from a user 102 amongst the user's multiple DVRsystems 103, if the user 102 operates multiple DVR systems 103. Resourcecapability/availability data 110 may include, for example, for each ofthe user's DVR systems 103, information about the multimedia contentstorage capability and availability of the DVR system and concurrentrecording capability of the DVR system.

In a possible embodiment, the schedule management logic 107 alsoperiodically synchronizes the repeat recording schedule(s) of the DVRsystem(s) 103 stored in local memories of the DVR system(s) 103 with therepeat recording schedule(s) 111 for the DVR system(s) 103 stored in thedatabase(s) 109. These and other program schedule management operationsperformed by schedule management logic 107 are described in greaterdetail below.

For the purpose of providing a clear example, schedule management logic107 and user interface logic 108 are shown separately in FIG. 1.However, some or all of schedule management logic 107 may be implementedas part of user interface logic 108 and vice versa. Further, schedulemanagement logic 107 and user interface logic 108 each may perform otherfunctions and operations in addition to the functions and operationsdescribed herein. Schedule management logic 107 and user interface logic108 may be implemented as software, hardware, or combination of softwareand hardware.

The database(s) 109 stores resource capabilities and availabilities data110 for the DVR system(s) 103, repeat recording schedule data 111 forthe DVR system(s) 103, program guide data 112 for the DVR system(s) 103,and account information for the user(s) 102. The database(s) 109 may beimplemented using any type of database suitable for the implementationat hand and the invention is not limited to any particular type ofdatabase. For example, the database(s) 109 may be a relational database,a set of eXtensible Markup Language (XML) files, object database, acombination of different database types, etc.

The content provider(s) 101, the DVR system(s) 103, the personalcomputing device(s) 104, and the server(s) 106 may each becommunicatively coupled to one or more of the others via one or moredata networks. The content provider(s) 103, the DVR system(s) 103, thepersonal computing device(s) 104, and the server(s) 106 may each beconnected to the one or more data networks via wired or wirelessconnections. Typical wired connections include but are not limited toEthernet, narrowband POTS, xDSL, Hybrid Fiber Coaxial (HFC) and cable,which can utilize twisted pair copper wires, coaxial cable, fiber or anycombination thereof. Typical wireless connections include but are notlimited to Wireless LAN (IEEE 802.11), Cellular, PCS, CDPD, GPRS, andBluetooth, each of which typically operate at a particular radiofrequency.

Personal computing device(s) 104 can include desktop computers, laptopcomputers, tablet computers, handheld computing devices such as cellularphones and portable media players, and the like. In one possibleembodiment, a personal computing device 104 is configured with a webbrowsing or similar application capable of interfacing with the serviceprovider 105 through user interface logic 108. In this embodiment, userinterface logic 108 is capable of driving display of web pages and webcontent at the personal computing device(s) 104, responding to requestsfrom the personal computing device(s) 104 (e.g., HyperText TransferProtocol (HTTP)-based requests, etc.), and providing responses to therequests to the personal computing device(s) 104. In another possibleembodiment, a personal computing device 104 is configured with a nativedesktop application capable of interfacing with the service provider 105through user interface logic 108. In this embodiment, user interfacelogic 108 is capable of responding to requests (e.g., TransmissionControl Protocol/Internet Protocol (TCP/IP) requests) from the nativeapplication executing on the personal computing device and providingresponses to the requests to the native application. The nativeapplication uses information in the returned responses to drive a userinterface presented on a display of the personal computing device.

The content provider(s) 101 may provide multimedia content andprogramming to the DVR system(s) 103 via radio frequency broadcast,satellite signal, cable television (CATV) signal, data network, etc. Themultimedia content and programming may include a combination of text,data, audio, still images, animation, video, interactivity, etc. Thecontent provider(s) 101 may also provide multimedia content andprogramming to the DVR system(s) 103 over a data network. For example, acontent provider 101 may unicast, multicast, or broadcast multimediacontent and programming to the DVR system(s) 103 over one or more datanetworks using an Internet Protocol (IP)-based network protocol. DVRsystem(s) 103 may also download or retrieve multimedia content fromcontent provider 101 servers over one or more data networks using anIP-based network protocol.

4.0 EXAMPLE DVR SYSTEM

Referring now to FIG. 2, therein is shown a block diagram and schematicillustration of components of an example DVR system 203, according to apossible embodiment of the invention. DVR system 203 generally comprisesone or more components, signified by signal converter 215, that may beused to accept a digital data stream or digitize an analog televisionsignal and convert it into a digital data stream. An example of theinternal structure and operation of a DVR system is further described inU.S. Pat. No. 6,233,389, the entire contents of which is herebyincorporated by reference as if fully set forth herein.

DVR system 203 receives broadcast signals from an antenna, from a cableTV system, satellite receiver, etc., via input 214A. Input 214A maycomprise one or more tuning modules (“tuners”) that allow one or moresignals to be received and recorded simultaneously. For example, a TVinput stream received by input 214A may take the form of a NationalTelevision Standards Committee (NTSC) compliant signal or a PhaseAlternating Line (PAL) compliant broadcast signal. For another example,a TV input stream received by input 214A may take a digital form such asa Digital Satellite System (DSS) compliant signal, a Digital BroadcastServices (DBS) compliant signal, an Advanced Television StandardsCommittee (ATSC) compliant signal, MPEG-4, etc. DBS, DSS, and ATSC arebased on standards called Moving Pictures Experts Group 2 (MPEG-2) andMPEG-2 Transport. MPEG-2 Transport is a standard for formatting thedigital data stream from the TV source transmitter so that a TV receivercan disassemble the input stream to find programs in the multiplexedsignal.

An MPEG-2 transport multiplex supports multiple programs in the samebroadcast channel with multiple video and audio feeds and private data.Input 214A tunes to a particular program in a channel, extracts aspecified MPEG stream from the channel, and feeds the MPEG stream to therest of the system. Analog TV signals are encoded into a similar MPEGformat using separate video and audio encoders, such that the remainderof the system is unaware of how the signal was obtained. Information maybe modulated into the vertical blanking interval (VBI) of the analog TVsignal in a number of standard ways; for example, the North AmericanBroadcast Teletext Standard (NABTS) may be used to modulate informationonto certain lines of an NTSC signal, which the FCC mandates the use ofa certain other line for closed caption (CC) and extended data services(EDS). Such signals are decoded by input 214A and passed to the othermodules as if the signals had been delivered via an MPEG-2 private datachannel.

Recording module 217 records the incoming data stream by storing thedigital data stream on at least one storage facility, signified bystorage 220A/220B that is designed to retain segments of the digitaldata stream. Storage 220A/220B may be one or more non-volatile storagedevices (e.g., hard disk, solid state drive, USB external hard drive,USB external memory stick, USB external solid state drive, networkaccessible storage device, etc.) that are internal 220A and/or external220B. A signal converter 215 retrieves segments of the data stream,converts the data stream into an analog signal, and then modulates thesignal onto a RF carrier, via output 214B, through which the signal isdelivered to a standard TV set. Output 214B may alternatively deliver adigital signal to a TV set or video monitor with signal converter 215,converting the data stream into an appropriate digital signal. Forexample, DVR system 203 may utilize a High-Definition MultimediaInterface (HDMI) for sending digital signals to a TV via a HDMI cable.

DVR system 203 also includes a communication interface 219, throughwhich the DVR system 203 communicates with a data network via Ethernet,wireless network, modem, or other communications standard. DVR system203 may communicate (e.g., send and receive data) with service provider105 server(s) 106 via communication interface 219 using aconnection-oriented transport protocol (e.g., TCP/IP) or aconnectionless transport protocol (e.g., UDP). Communication between theDVR system 203 and service provider 105 may use a secure distributionarchitecture to transfer data between the DVR system 203 and the serviceprovider 105 such that both the service data and the user's privacy areprotected.

DVR system 203 may also receive multimedia content streams (e.g., MPEG-2transport streams, MPEG-4 transport streams, etc.) from contentprovider(s) 102 via communication interface 219. For example, a contentprovider 102 may deliver a multimedia content stream to communicationinterface 219 via Internet Protocol (IP) multicast or via IP unicast.DVR system 203 may retrieve a multimedia content stream from contentprovider(s) 102 via communication interface 219. Multimedia contentstreams received via communication interface 219 can be provided torecording module 217 for storage on storage 220A/220B.

The DVR system 203 may be integrated into a TV system such that thecomponents described above are housed in a TV set capable of performingthe functions of each component of the DVR system 203.

In another possible embodiment, the DVR system 203 generally comprisesone or more components necessary to receive, record, store, transfer andplayback digital data signals from one or more sources, such as a PC, aDVR, a content provider, or content server. The DVR system 203 cantransfer digital data signals to another DVR, PC, or any other suitablyconfigured device, such as a handheld device, cell phone, etc. The DVRsystem 203 may encode or decode digital signals via encoder 216A anddecoder 216B into one or more formats for playback, storage or transfer.According to a possible embodiment, encoder 216A produces MPEG streams.According to another possible embodiment, encoder 216A produces streamsthat are encoded using a different codec. Decoder 216B decodes thestreams encoded by encoder 216A or streams that are stored in the formatin which the streams were received using an appropriate decoder. The DVRsystem 203 can also encrypt or decrypt digital data signals usingencryptor/decryptor 218 for storage, transfer or playback of the digitaldata signals.

5.0 EXAMPLE DVR SYSTEM REGISTRATION

In one possible embodiment, a DVR system registration process isperformed before the service provider begins management of repeatrecording schedules for the DVR system. Referring to FIG. 3, therein isshown in flowchart form steps of an example DVR system registrationprocess 300. The process 300 is performed by logic (e.g., software,firmware, etc.) executed by one or more server(s) 106 of the serviceprovider 105. In one possible embodiment, the process is initiatedbefore the given DVR system has been delivered to or purchased by a user102.

At step 301, an identifier of the given DVR system is obtained. Anyidentifier that uniquely identifies the given DVR system may be used.For example, the serial number of the given DVR system or othermanufacturer assigned identifier. In one possible embodiment, theidentifier is obtained before the given DVR system is delivered to orpurchased by a user. For example, as part of inventory processingperformed by the service provider, the identifier may be entered intothe database(s) 150.

In another possible embodiment that is not exclusive of a possibleembodiment in which the identifier is obtained before the given DVRsystem is delivered to or purchased by a user, the identifier isobtained from the given DVR system after the given DVR system has beenconfigured by the user at a place of deployment (e.g., the user's home).Note that the place of deployment need not be fixed such as when, forexample, the DVR system is part of a mobile computing device. In thisembodiment, the given DVR system is operatively coupled by the user to adata network that connects the given DVR system to the service provider.Once coupled, the given DVR system detects and communicates theidentifier to the service provider. Upon receiving the identifiercommunicated by the DVR system, the identifier is stored in the serviceprovider database(s).

In one possible embodiment, the DVR system comprises executable logic(e.g., executable software or firmware instructions) which, whenexecuted by the DVR system, determines an identifier for the DVR systemand communicates the identifier to the service provider over the datanetwork. Communication can be initiated by the service provider or theDVR system. For example, the DVR system or the service provider mayinitiate and establish a Transmission Control Protocol (TCP) connectionto the other and over which the identifier of the DVR system iscommunicated from the DVR system to the service provider. The logicexecuted by the DVR system may inspect or access a memory of the DVRsystem to obtain the identifier. The identifier may have been stored orburned-in the memory by the manufacturer of the DVR system.

In a possible embodiment, the logic for determining and communicatingthe identifier executed by the DVR system is provided to the DVR systemby the service provider. For example, the service provider may providethe logic to the DVR system in an initial communication with the DVRsystem after the DVR system has been operatively coupled to the datanetwork by the user.

At this point, the service provider has an identifier of the given DVRsystem stored in the database(s) but the identifier may not yet havebeen associated with a user account 113. At steps 302 and 303 of process300, a user account is created and associated in the database(s) withthe identifier of the given DVR system. To do so, in one possibleembodiment, the user of the DVR system accesses an account activationinterface of the service provider driven by user interface logic 108.The account activation interface may be accessed either through thegiven DVR system or a personal computing device 104 of the user. Forexample, the user may use a remote control device or other input deviceto interact with the account activation interface as presented on theuser's television screen to which the given DVR system is operativelycoupled. As another example, the user may use a web browsing applicationexecuting on the personal computing device to interact with the accountactivation interface.

Through the account activation interface the service provider collectsnecessary information for creating an account record in the database forthe user. Such information may include, for example, account credentials(e.g., username/password), contact information (e.g., an e-mailaddress), billing information, and the like. Once the necessaryinformation is collected, the service provider can create an accountrecord for the user in the service provider database(s).

To associate the account record created for the user with theidentifiers of the DVR systems the user operates, the account activationinterface may prompt the user to enter the identifiers of the DVRsystems when activating the account. For example, the user may beprompted by the account activation interface to provide external serialnumbers listed on the casings of the user's DVR systems. In conjunctionwith or after creating the account record, the service provider can linkin the database the account record with the DVR system identifiersentered by the user.

In one possible embodiment, the registration process uses twoidentifiers for each DVR system. One identifier uniquely identifies theDVR system such as, for example, a serial number or other identifierassigned by the manufacturer of the DVR system. This identifier can bethe same as the identifier discussed above that is obtained by theservice provider at step 301 of process 300. The other identifier isassigned by the service provider to the DVR system before the DVR systemis delivered to or purchased by a user. For the purpose of illustratinga clear example, the identifier of the DVR system obtained at step 301is referred to as the manufacturer identifier and the other identifierassigned to the DVR system by the service provider is referred to as theservice provider identifier. Both the manufacturer identifier and theservice provider identifier uniquely identify the DVR system. Theservice provider maintains a mapping in the database(s) betweenmanufacturer identifiers and service provider identifiers. Assignedservice provider identifiers are affixed to or associated with the DVRsystems before the DVR systems are delivered to or purchased by users.For example, assigned service provider identifiers may be printed onadhesive stickers which are affixed to the casing of DVR systems orprinted in accompanying user manuals before the DVR systems aredelivered to or purchased by users. The user is prompted to provide theservice provider numbers of the user's DVR systems when activating anaccount by the account activation interface. Upon receiving the serviceprovider numbers, the service provider consults the mapping it maintainsto determine the manufacturer identifiers of the user's DVR systems.Having determining the manufacturer identifiers, the service providercan create associations between the manufacturer identifiers and theusers' account record in the service provider database. In this way, auser's account record can be associated with the identifiers of the DVRsystems operated by the user without the user having to obtain or knowabout the identifiers used by the service provider to identify the DVRsystems.

The above is but one example of a possible DVR system registrationprocess and other processes may be used. Significantly, by theculmination of the registration process, the service provider shouldhave obtained the identifiers of the user's DVR systems and the user'saccount activation information from which an account record can becreated for the user and an association made in the service providerdatabase(s) between the account record and the identifiers of the user'sDVR systems. Thus, after the registration process for all of a user'sDVR systems, the service provider can determine the identifiers of theDVR systems operated by the user and for a given identifier of a DVRsystem, the service provider can determine the account record of theuser that operates the given DVR system.

6.0 EXAMPLE PROGRAM GUIDE

Referring now to FIG. 4, therein is shown a block diagram and schematicillustration of an electronic program guide 400 according to a possibleembodiment of the invention. The service provider 105 may store data 112in the database(s) 150 representing electronic program guides forcontent provider(s) 101. Each program guide provides information aboutmultimedia programming and content offered by a content provider. Inparticular, each program guide specifies one or more channels 401offered by the content provider and for each channel, the programmingoffered by the content provider during a time widow 402. Each programguide may also or alternatively provide information about multimediaprogramming and content offered by a content provider across a datanetwork and accessible via a Uniform Resource Locator (URL), IP address,etc.

As used herein, the term “channel” refers broadly to any identifiercapable of being used by a DVR system to select one multimedia programof many multimedia programs currently being offered by the contentprovider. For example, a channel 401 may correspond to a broadcasttelevision, digital satellite television, or cable television channelnumber. As another example, a channel 401 may correspond to a URL orother web address.

As used herein, the term “multimedia program series” or just “programseries” refers broadly to multimedia content offered by a contentprovider on one or more channels either as a one-time offering or on aperiodic basis. For example, a multimedia program series may correspondto a television program, a television program series that includes aplurality of episodes, a webcast, a podcast, video content, audiocontent, etc. In the program guide 400, each program series isidentified by a title and a unique program identifier.

An instance of a program series is referred to herein as an “episode”.Program guide 400 segments channels 401 during the time window 402 intoseries of episodes. Each episode has a start time during the time window402 and an end time during the time widow 302. For example, episode 403Ahas start time 404 and an end time 405. Each episode identifies theprogram series the episode is a part of, for example, through theprogram identifier or through the program title. Each episode may alsobe further identified by an episode identifier or an episode title.

When a program series is offered by a content provider on a periodicbasis, the program guide 400 may indicate multiple episodes for the sameprogram series. For example, episode 403A and episode 403B may be twoepisodes of the same program series. Episodes of a program series may beoffered on multiple channels 401. For example, an episode for a programseries may be offered on one channel in a high definition video formatwhile offered on another channel in a regular definition video format.

The service provider may obtain or create program guides 400 on aperiodic basis as programming information for content providers becomesavailable. Program guides 400 may be obtained by the service providerfrom one or more third-party television listing services. The length ofthe time window 402 for a program guide 400 is largely dictated by howoften the content provider updates its programming schedule. A typicaltime widow 402 is two weeks in length. However, a time window 402 can beshorter, longer, list previous weeks or months of scheduling, etc.

The service provider 130 stores program guides 400 as program guide data112 in database(s) 150. The service provider periodically (e.g., once aday, once every few days, etc.) communicates program guide datarepresenting program guides to DVR systems 103. Each DVR system receivesprogram guide(s) corresponding to the content provider(s) that providemultimedia programming to the DVR system's geographical location orservice area. For example, if a DVR system receives multimedia contentfrom a particular cable television provider, then the service providerprovides program guide data for that particular cable televisionprovider.

7.0 EXAMPLE OF CREATING A REPEAT RECORDING SCHEDULE

Referring now to FIG. 5, therein is shown a flowchart of steps of aprocess 500 for creating a repeat recording schedule according to apossible embodiment of the invention. The process 500 is performed bylogic (e.g., software) executed by one or more server(s) 106 of theservice provider 105. The process is performed by the server logic inthe context of user interface logic 108 driving a user interfacedisplayed on a display device operatively coupled to a user 120's DVRsystem 103 or a personal computing device 104 of the user.

At step 501, the service provider logic receives a selection of aparticular DVR system to configure with a repeat recording schedule(e.g., from a user via a web interface over the Internet, via a handhelddevice using a wireless or cellular connection, etc.). If the user hasregistered multiple DVR systems with the service provider, then theservice provider logic may receive the selection in response to the userselecting one of the multiple DVR systems through the user interface. Ifthe user has registered only one DVR system with the service provider,then the service provider logic may receive the selection of the one DVRsystem as a default selection. Alternatively, the service provider logicmay receive the selection of the one DVR system after the user has beenprompted through the user interface to confirm configuration of the oneDVR system with a repeat recording schedule.

In response to receiving the selection of a particular DVR system, theservice provider logic determines the identifier of the particular DVRsystem from the database(s) 150 for use in handling subsequent requestsregarding creating the repeat recording schedule for the particular DVRsystem.

At step 502, the service provider logic receives a request to search orbrowse program guide(s) 112 for the selected DVR system for a programseries or multiple program series of interest for recording on a repeatbasis. The program guide(s) 112 for the selected DVR system can beidentified by the service provider logic using the selected DVR system'sidentifier. For example, the database(s) 150 may store dataassociation(s) between the selected DVR system's identifier and theprogram guide(s) 112 for the selected DVR system. The search or browserequest may be received in response to the user submitting search orbrowse criteria to the service provider logic through the userinterface. For example, the user interface may facilitate a keywordsearch for programs by program title. As another example, the userinterface may facilitate browsing listings of programs by program seriestitle. In response to receiving the search or browse request, theservice provider logic searches the program guide(s) 112 for theselected DVR system to identify a program series or multiple programseries in the program guide(s) that match the submitted search or browsecriteria. Matching program(s) are returned to the user interface.

In one possible embodiment, matching program series are presented to theuser on the user interface as a set of search or browse results. Eachresult in the set corresponds to a matching program series. In onepossible embodiment, each result indicates the title of the matchingprogram series and the channel that the matching program series isavailable on. If a program series is available on multiple channels,then the search results may include multiple results for that programseries.

At step 503, the service provider logic receives a selection of aparticular program series-channel combination of interest for recordingon a repeat basis. For example, the selection may be received inresponse to the user selecting one of the matching results presented asa search or browse results in the user interface.

Along with or after receiving the selection of the particular programseries, the service provider may also receive one or more recordingoptions. These recording options may be selected by the user through theuser interface. In one possible embodiment, the recording optionsavailable for selection and configuration by the user include “recordingquality”, “record”, “keep at most”, “keep until”, “start recording”,“stop recording”, etc.

The “recording quality” option allows the user to specify the quality(e.g., basic, medium, high, or best) of the recording by the DVR systemwhen recording episodes of the selected program series. A higher qualityrecording generally provides a better playback experience when viewing arecorded episode at the expense of requiring more storage space of theDVR system to store the recorded episode. This is because a higherquality recording is made at a higher bit-rate than a lower qualityrecording.

The “record” option allows the user to specify whether only new episodesof the program series offered on the channel are recorded by theselected DVR system or whether new and repeat episodes of the programseries offered on the channel are recorded by the selected DVR system.In one possible embodiment, indication of whether an episode of aprogram series offered on a channel is a new episode or a repeat episodeis provided in the program guide data.

The “keep at most” option allows the user to specify a maximum number ofepisodes of the selected program series to record. The DVR system willdelete oldest or lower priority recorded episodes of the program serieswhen making a new recording of an episode of the program series. Forexample, if the user specifies two (2) for the “keep at most” option,the first episode of the program series will be deleted by the DVRsystem when the third episode of the program series is recorded by theDVR system.

In one possible embodiment, the “keep at most” option operates inconjunction with the “keep until” option. If the “keep until” option isset to “when space needed” as described below, the most recentlyrecorded episodes will be kept, as described above, when a new recordingis made. If the “keep until” option is set to “keep until delete” asdescribed below, all episodes of the program series will be kept when anew recording is made until the “keep at most” limit is reached. Forexample, if the “keep at most” option is set to three (3) episodes andthe “keep until” option is set to “keep until delete”, then the DVRsystem will stop recording episodes of the program series after threeepisodes of the program series have been recorded until the user deletesone or more of the three recorded episodes.

The “keep until” option allows the user to specify when recordedepisodes are deleted by the DVR system. In one possible embodiment, the“keep until” option can assume two values: “when space needed” or “keepuntil delete”. If the “keep until” option is set to “when space needed”,the oldest recorded episodes of a program series will be deleted by theDVR system as space is needed for new recordings. If the “keep until”option is set to “keep until delete”, all recorded episodes are saveduntil the user manually deletes.

The “start recording” option allows the user to specify that the DVRsystem should start recording an episode of the selected program seriesbefore the episode is scheduled to begin (e.g., 1, 2, 3, 4, 5, . . . 10,etc., minutes prior—any number of minutes and/or hours prior). The “stoprecording” option allows the user to specify that the DVR system shouldstop recording an episode of the selected program series after thescheduled end of the program (e.g., 1, 2, 5, 15, 30 minutes, 1 hour, 1.5hours, or 3 hours after, etc.—any number of minutes and/or hours after).

At step 504, the service provider logic adds the selected program seriesand selected recording options to the repeat recording schedule 111 forthe selected DVR system. In one possible embodiment, the repeatrecording schedule for the DVR system comprises an ordered listing ofprogram identifier-channel tuples. The program identifier and channel ofa selected program series may be determined from the program guide fromwhich the program of interest was selected.

In one possible embodiment, the repeat recording schedule is prioritizedto resolve a recording concurrency conflict amongst repeat recordings.In general, a recording concurrency conflict arises when a DVR systemconfigured with a repeat recording schedule is configured toconcurrently record more episodes than it is capable of concurrentlyrecording. Concurrent recording capability of a DVR system may belimited by the inherent computing processing power of the DVR system orthe number of tuners or inputs the DVR system is configured with.

In one possible embodiment, when a recording concurrency conflictarises, the DVR system will record the episode of the program serieswith the higher priority according to the repeat recording schedule andwill clip the recording (e.g., start the recording after the higherpriority recording completes) of the episode of the program series withthe lower priority.

In one possible embodiment in which two concurrently conflictingepisodes overlap by only a few minutes, recording of the lower priorityepisode is canceled. For example, if an episode of a lower priorityprogram series ends at 8:33 while an episode of a higher priorityprogram series begins at 8:30, then the recording of the lower priorityepisode will be canceled at 8:30 so that recording of the higherpriority episode can then begin.

Steps 502, 503, and 504 may be repeated if the user desires to add moreprogram series to the repeat recording schedule of the selected DVRsystem.

At step 505, service provider logic synchronizes the copy of the repeatrecording schedule 111 stored in the database(s) 150 with the copy ofthe repeat recording schedule stored on the selected DVR system. In onepossible embodiment, the synchronization is bi-directional such thatsuperseding changes made to the copy of the repeat recording schedule atthe DVR system are incorporated into the copy of the repeat recordingschedule 111 in the service provider database(s) 150 and supersedingchanges made to the copy of the repeat recording schedule 111 in theservice provider database(s) 150 are incorporated into the copy of therepeat recording schedule at the DVR system. Any number of techniquesmay be used to detect superseding changes when synchronizing the copiesof the repeat recording schedules including use of change timestamps,vector clocks, etc. Synchronization of the copies may be initiated byDVR system or the service provider. In one possible embodiment,synchronization of the copies includes one of the DVR system or theservice provider initiating and establishing a TCP connection to theother. Synchronization may occur periodically for example in response toevery user initiated change to a copy of the repeat recording schedule.

In one possible embodiment, after the copies of the repeat recordingschedule have been synchronized, both the copy of the schedule at DVRsystem and the copy of the schedule in the service provider database(s)150 are the same. That is, both copies list the same program-channelcombinations in the same priority ordering. The bi-directionalsynchronization ability allows the user to configure a DVR system with arepeat recording schedule even if the data connection between the DVRsystem and the service provider is temporarily unavailable. For example,if the data connection is temporarily unavailable, the user can makechanges to the DVR system's copy of the repeat recording schedule usingcontrols of the DVR system. When the data connection is reestablished,those changes may be synchronized with the copy of the repeat recordingschedule for the DVR system stored in the service provider database(s)150.

In one possible embodiment, the bi-directional synchronization abilityallows the user to configure a DVR system with a repeat recordingschedule even if the user does not have physical access to the DVRsystem. For example, using a web browsing application on a personalcomputing device, the user can interact with the user interface logic108 of the service provider to configure a repeat recording schedule forthe DVR system from anywhere the personal computing device can establisha data connection with the service provider. For example, if the user iswaiting for an airplane flight in an airport terminal, the user may beable to configure his home DVR system with a repeat recording scheduleat the airport by accessing the service provider web interface throughan Internet connection between a mobile device of the user and theservice provider.

8.0 EXAMPLE OF CREATING A REPEAT RECORDING SCHEDULE FOR A DVR SYSTEMBASED ON ANOTHER REPEAT RECORDING SCHEDULE FOR ANOTHER DVR SYSTEM

Referring now to FIG. 6, therein is shown a flowchart of steps of aprocess 600 for creating a repeat recording schedule for a DVR system(Target DVR system) based on an another repeat recording schedulecreated for another DVR system (Source DVR system), according to apossible embodiment of the invention. The process is performed by logic(e.g., software) executed by one or more server(s) 106 of the serviceprovider 105. The process is performed by the server logic in thecontext of user interface logic 108 driving a user interface displayedon a display device operatively coupled to a user 120's DVR system 103or a personal computing device 104 of the user.

In one possible embodiment, process 600 is performed in the context of auser upgrading an existing DVR system with a new DVR system. In thisembodiment, both the existing DVR system and the new DVR system may beoperatively coupled to the service provider via a data network. The userinteracts with the user interface logic 108 of the service providerserver 105 to copy repeat recording requests from the repeat recordingschedule 111 of the existing DVR system to the repeat recording schedule111 of new DVR system. Note that the process described herein may alsoapply to other features of the DVR system, e.g., user preferences, userviewing preferences, user viewing history, system settings, predictiverecording data, etc.

At step 601, the service provider logic receives a selection of a firstDVR system. The selection may be received in response to the userselecting one of the user's multiple registered DVR systems through auser interface (e.g., a web page, etc.) caused to be presented to theuser by user interface logic 108. In response to receiving the selectionof the first DVR system, the service provider logic reads the currentrepeat recording schedule 111 for the first DVR system from thedatabase(s) 109 and returns the repeat recording schedule 111 to therequesting entity to be presented on the user interface. Alternatively,the service provider logic may retrieve the repeat recording schedule111 directly from the first DVR system.

At step 602, the service provider logic receives a selection of a secondDVR system. The selection may be received in response to the userselecting one of the user's multiple registered DVR systems through auser interface (e.g., a web page, etc.) caused to be presented to theuser by user interface logic 108. In response to receiving the selectionof the second DVR system, the service provider logic reads the currentrepeat recording schedule 111 for the second DVR system from thedatabase(s) 109 and returns the repeat recording schedule 111 to therequesting entity to be presented on the user interface. Alternatively,the service provider logic may retrieve the repeat recording schedule111 directly from the second DVR system.

Referring to FIG. 7A, therein is shown an exemplary user interface 700presenting a current repeat recording schedule 111 for a first DVRsystem 701 of a user's multiple DVR systems and a current repeatrecording schedule 111 for a second DVR system 702 of the user'smultiple DVR systems.

As shown in FIG. 7A, the program series currently on a particular DVRsystem's repeat recording schedule may be presented on the userinterface in an order based on the associated program recordingpriorities. For example, the repeat recording schedule of the first DVRsystem 701 currently has the program series “Community” on channel 703as the highest priority followed by the program series “The Big BangTheory” on channel 5 as the next highest priority, etc. The prioritiesassociated with the program series currently on system 701's repeatrecording schedule are listed in decreasing priority order (numericallyincreasing order) in the “Priority” column 707 of the user interface700. The priorities associated with the program series currently on thesystem 702's repeat recording schedule are listed in decreasing priorityorder (numerically increasing order) in the “Priority” column 708 of theuser interface 700.

In one possible embodiment, priorities of the program series on asystem's repeat recording schedule can be reordered through userinterface 700. For example, the user may change the priority of aprogram series by clicking and dragging a user interface itemrepresenting the program series up or down the list of items andreleasing at the desired priority location. The other items in the listare accordingly assigned new priorities. For example, referring to theuser interface 700, a user may click and drag the user interface itemcorresponding to the program series “The Event” on channel 3. If theuser releases the item between the items corresponding to the twoprogram series “Chuck” on channel 703 and “The Office” on channel 12,then “The Event” on channel 3 would be reassigned a priority of 3,“Cougar Town” on channel 707 would be reassigned a priority of 1,“Chuck” on channel 703 would be reassigned a priority of 2.

In one possible embodiment, a user may delete a program series from asystem's repeat recording schedule through the user interface 700. To doso, the user may individually select one or more program series todelete using the checkboxes next to the corresponding user interfaceitems. Alternatively, the user may designate all program series to bedeleted using the “Check all” checkbox. Once the one or more programseries to delete have been selected, the user may select the “Delete”button for the corresponding repeat recording schedule which causes theselected program series to be removed the repeat recording schedule 111.

In one possible embodiment, when a repeat recording schedule 111 for aDVR system is modified through the user interface logic 108 either byreordering priorities or by deleting program series, the resultingchanges to the repeat recording schedule 111 is synchronized with thesystem's copy of the repeat recording schedule as a result of asubsequent bi-directional synchronization operation performed by theschedule management logic 107 and the DVR system.

The first DVR system 701 and the second DVR system 702 represent DVRsystems that the user wishes to copy repeat recording requests between.In the example depicted in FIG. 7, the first DVR system 701 is locatedin the user's living room while the second DVR system 702 is located inthe user's master bedroom.

As shown, the user interface 700 provides a set of checkboxes 703whereby the user can select one or more or all of the repeat recordingrequests of the current repeat recording schedule 111 for the first DVRsystem 701. The user interface 700 provides another set of checkboxes704 whereby the user can select one or more or all of the repeatrecording requests of the current repeat recording schedule 111 for thesecond DVR system 702. The user interface 700 also provides a button 705for copying selected repeat recording requests from the repeat recordingschedule 111 for the first DVR system 701 to the repeat recordingschedule 111 for the second DVR system 702. There is also a button 706for copying selected repeat recording requests from the repeat recordingschedule 111 for the second DVR system 702 to the repeat recordingschedule 111 for the first DVR system 701. Thus, bi-directional copyingis facilitated. In the example depicted in FIG. 7B, some of the repeatrecording request from the current repeat recording schedule for thefirst DVR system 701 have been selected. The selections are indicatedwith a check in the correspond checkboxes 703.

At step 603, the service provider logic receives a request to copy oneor more selected repeat recording requests from the repeat recordingschedule of the first or second DVR systems (source DVR system) to theother of the first or second DVR systems (target DVR system). Forexample, in the example depicted by FIG. 7B, the user has selected tocopy the repeat recording requests for “Community”, “Men of a CertainAge”, and “How I Met Your Mother” from the repeat recording schedule for“Living Room” DVR system 701 to the repeat recording schedule for the“Master Bed” DVR system 702. In response to the user activating the copybutton 705, the service provider logic receives the copy request.

In the case where the source DVR system uses the same program guide(s)112 as the target DVR system, the selected repeat recording requestsfrom the source DVR system's repeat recording schedule can be copieddirectly to the target DVR's repeat recording schedule. This is becausethe program identifiers and channels of the selected programs will bethe same in both systems' program guide(s) 112.

In the case where the source DVR system uses a different program guide112 from the target DVR system, in response to receiving the copyrequest at step 603, the service provider logic searches the programguide(s) 112 of the target DVR system for episodes that correspond tothe one or more program series selected from the source DVR system'srepeat recording schedule. This search may be made based on one or moreof the program identifiers and the program titles of the selected one ormore program series. Typically, the same program series is identified bythe same program identifier across different program guide(s) 112, evenif the program is offered on different channels. For example, in theexample of FIG. 7B, the service provider logic could search the programguide(s) 112 for the “Master Bed” target DVR system 702 for episodesthat refer to program identifiers equal to the program identifiers forthe program series “Community”, “Men of a Certain Age”, and “How I MetYour Mother” as specified in the “Living Room” source DVR system's 701repeat recording schedule. In situations where consistent programidentifiers are not used, the program title may be used to identifyprogram series in the target DVR system's program guide(s) 112. Forexample, the service provider logic could search the program guide(s)112 for the “Master Bed” target DVR system 702 for episodes with theprogram series title of “Community”, “Men of a Certain Age”, or “How IMet Your Mother”.

In one possible embodiment, if at least one episode is identified in theprogram guide(s) 112 of the target DVR system that is associated with aprogram series that matches a selected program series to be copied, thenthe user is prompted in the user interface to confirm the addition ofthe program to the target DVR system's repeat recording schedule. Ifmore than one episode is identified for the same program series but ondifferent channels, the user may be prompted to confirm the addition ofsome or all of the program series-channel combinations. For example, aselected program series may be provided by a content provider to thesource DVR system on only a standard definition channel while providedto the target DVR system by a content provider on a standard definitionchannel and a high-definition channel. In this example, the user may beprompted to confirm the addition of one or both of the program series onthe standard definition channel and the program series on the highdefinition channel to the target DVR system's repeat recording schedule.

At step 604, one or more of the program series identified in the targetDVR system's program guide(s) 112 that match or correspond to theprogram series selected from the source DVR system's repeat recordingschedule 111 are added to the target DVR system's repeat recordingschedule 111. The program identifier and channel of a selected programseries to be copied that is added to the repeat recording schedule 111for the target DVR system may be determined by the service providerlogic from the program guide(s) 112 for the target DVR system from whichthe episode(s) of the program series to be copied were identified. Afterthe target DVR system's repeat recording schedule 111 has been createdor updated, the new repeat recording schedule 111 for the target DVRsystem may be presented on the user interface so that the user canarrange the priorities (e.g., by clicking and dragging a program up ordown the list and releasing at the desired priority location, etc.) ofthe repeat recording requests according to the user's preferences.

At step 605, the service provider logic synchronizes the copy 111 of therepeat recording schedule for target DVR system with the copy of therepeat recording schedule stored at the target DVR system.

Steps 603, 604, and 605 may be repeated if the user desires to copy moreprogram series from the repeat recording schedule of the source DVRsystem to the repeat recording schedule of the target DVR system. Steps603, 604, and 605 may be performed where a first system is the sourceDVR system and a second system of the target DVR system and thenperformed again where the second system is the source DVR system and thefirst system is the target DVR system. For example, referring to FIG.7A, steps 603, 604, and 605 may be performed where system 701 is thesource DVR system and system 702 is the target DVR system and thenperformed against where system 701 is the target DVR system and system702 is the source DVR system.

9.0 EXAMPLE OF PREVENTING CONCURRENT RECORDING CONFLICTS

Referring now to FIG. 8, therein is shown a flowchart of steps of aprocess 800 for preventing a concurrent recording conflict, according toa possible embodiment of the invention. In general, a concurrentrecording conflict arises when a DVR system is scheduled according toits repeat recording schedule to concurrently record from more channelsand/or inputs than the DVR system is capable of recording from at thesame time. The DVR system may be limited in the number of channelsand/or inputs it can concurrently record from by the processing powerand capabilities of the DVR system. For example, a DVR system with onlytwo tuners may only be able to record from the two channelssimultaneously. In the event of a concurrent recording conflict, the DVRsystem may consult its repeat recording schedule to determine which ofthe conflicting program series is of lowest priority according therepeat recording schedule. Episodes of program series with the lowestpriority are not recorded in favor of concurrent episodes of higherpriority program series.

In one possible embodiment, to prevent such a concurrent recordingconflict from arising at a particular DVR system 103 in the first place,the service provider logic at step 801 receives or obtains informationabout the particular DVR system's concurrent recording capability andstores the information in association with the DVR system's identifierin the service provider database(s) 150.

In one possible embodiment, the received or obtained informationcomprises a number indicating the number of channels and/or inputs thatthe particular DVR system can concurrently record from. This number maycorrespond, for example, to the number of tuners of the particular DVRsystem.

In one possible embodiment, DVR systems 103 periodically reportconcurrent recording capability information to the service provider overa data network.

At step 802, the service provider logic detects a concurrent recordingconflict for the particular DVR system. In one possible embodiment, theservice provider logic detects a concurrent recording conflict beforeattempting to add a repeat recording request to the particular DVRsystem's repeat recording schedule 111. To detect the conflict, theservice provider logic analyzes the program guide(s) 112 for theparticular DVR system to identify the start and end times of allepisodes of the program to be added to the particular DVR system'srepeat recording schedule 111. The service provider logic compares theseblocks of time with the start and end times of all episodes of the oneor more program series that are currently listed in the particular DVRsystems' repeat recording schedule 111. The start and end times of allepisodes of programs that are currently listed in the particular DVRsystem's repeat recording schedule 111 can be determined from theprogram guide(s) 112 for the particular DVR system. If there is a timeoverlap between an episode of the program series to be added and anepisode of a program series already listed in the particular DVRsystem's repeat recording schedule 111, then a conflict exists. If thenumber of overlapping episodes including the episode of the programseries to be added exceeds the concurrent recording capability of theparticular DVR system, then the service provider logic detects theaddition of the program to the particular DVR system's repeat recordingschedule 111 as presenting a concurrent recording conflict.

In one possible embodiment, the time window over which conflicts may bedetected is limited by the time windows 402 of the program guide(s) 112for the particular DVR system. For example, if the time window 402 istwo weeks in length, then the service provider logic may only detectconcurrent recording conflicts within the two week window.

In one possible embodiment, if episodes overlap by only a few minutes(e.g., less than five minutes), then the overlap is not considered topresent a concurrent recording conflict. In this embodiment, theparticular DVR system may clip the recording of one of the overlappingepisodes so that recording of another episode can begin. For example, ifan episode of the program series to be added ends three minutes after anepisode of a program series already listed in the particular DVRsystem's repeat recording schedule 111 starts, this overlap may not bedetected as a concurrent recording conflict because the particular DVRsystem may stop recording the episode of the program series to be addedthree minutes before it ends or not begin recording the other episodeuntil three minutes after that episode starts.

At step 803, the user is notified of the concurrent recording conflict.For example, in response to a request by the user to add a selectedprogram series to a repeat recording schedule 111 for a particular DVRsystem, the service provider logic may notify the user through the userinterface logic 108 that the addition of the selected program wouldpresent a concurrent recording conflict. Upon receiving suchnotification that user may decide not to schedule the selected programas originally requested. For example, the user may select another of theuser's DVR systems to record the selected program series by adding theselected program to the repeat recording schedule 111 of the othersystem. As another example, the user may prioritize the selected programseries higher than the conflicting program series in the particular DVRsystem's repeat recording list to ensure that episodes of the selectedprogram series are recorded by the particular DVR system.

10.0 EXAMPLE COMPUTING DEVICE

According to one possible embodiment, the techniques described hereinare implemented by one or more special-purpose computing devices. Thespecial-purpose computing devices may be hard-wired to perform thetechniques, or may include digital electronic devices such as one ormore application-specific integrated circuits (ASICs) or fieldprogrammable gate arrays (FPGAs) that are persistently programmed toperform the techniques, or may include one or more general purposehardware processors programmed to perform the techniques pursuant toprogram instructions in firmware, memory, other storage, or acombination. Such special-purpose computing devices may also combinecustom hard-wired logic, ASICs, or FPGAs with custom programming toaccomplish the techniques. The special-purpose computing devices may bedesktop computer systems, portable computer systems, handheld devices,networking devices or any other device that incorporates hard-wiredand/or program logic to implement the techniques.

For example, FIG. 9 is a block diagram that illustrates a computersystem 900 upon which a possible embodiment of the invention may beimplemented. Computer system 900 includes a bus 902 or othercommunication mechanism for communicating information, and a hardwareprocessor 904 coupled with bus 902 for processing information. Hardwareprocessor 904 may be, for example, a general purpose microprocessor.

Computer system 900 also includes a main memory 906, such as a randomaccess memory (RAM) or other dynamic storage device, coupled to bus 902for storing information and instructions to be executed by processor904. Main memory 906 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by processor 904. Such instructions, when stored innon-transitory storage media accessible to processor 904, rendercomputer system 900 into a special-purpose machine that is customized toperform the operations specified in the instructions.

Computer system 900 further includes a read only memory (ROM) 908 orother static storage device coupled to bus 902 for storing staticinformation and instructions for processor 904. A storage device 910,such as a magnetic disk or optical disk, is provided and coupled to bus902 for storing information and instructions.

Computer system 900 may be coupled via bus 902 to a display 912, such asa cathode ray tube (CRT), for displaying information to a computer user.An input device 914, including alphanumeric and other keys, is coupledto bus 902 for communicating information and command selections toprocessor 904. Another type of user input device is cursor control 916,such as a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to processor 904 and forcontrolling cursor movement on display 912. This input device typicallyhas two degrees of freedom in two axes, a first axis (e.g., x) and asecond axis (e.g., y), that allows the device to specify positions in aplane.

Computer system 900 may implement the techniques described herein usingcustomized hard-wired logic, one or more ASICs or FPGAs, firmware and/orprogram logic which in combination with the computer system causes orprograms computer system 900 to be a special-purpose machine. Accordingto one possible embodiment, the techniques herein are performed bycomputer system 900 in response to processor 904 executing one or moresequences of one or more instructions contained in main memory 906. Suchinstructions may be read into main memory 906 from another storagemedium, such as storage device 910. Execution of the sequences ofinstructions contained in main memory 906 causes processor 904 toperform the process steps described herein. In alternative possibleembodiments, hard-wired circuitry may be used in place of or incombination with software instructions.

The term “storage media” as used herein refers to any non-transitorymedia that store data and/or instructions that cause a machine tooperation in a specific fashion. Such storage media may comprisenon-volatile media and/or volatile media. Non-volatile media includes,for example, optical or magnetic disks, such as storage device 910.Volatile media includes dynamic memory, such as main memory 906. Commonforms of storage media include, for example, a floppy disk, a flexibledisk, hard disk, solid state drive, magnetic tape, or any other magneticdata storage medium, a CD-ROM, any other optical data storage medium,any physical medium with patterns of holes, a RAM, a PROM, and EPROM, aFLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from but may be used in conjunction withtransmission media. Transmission media participates in transferringinformation between storage media. For example, transmission mediaincludes coaxial cables, copper wire and fiber optics, including thewires that comprise bus 902. Transmission media can also take the formof acoustic or light waves, such as those generated during radio-waveand infra-red data communications.

Various forms of media may be involved in carrying one or more sequencesof one or more instructions to processor 904 for execution. For example,the instructions may initially be carried on a magnetic disk or solidstate drive of a remote computer. The remote computer can load theinstructions into its dynamic memory and send the instructions over atelephone line using a modem. A modem local to computer system 900 canreceive the data on the telephone line and use an infra-red transmitterto convert the data to an infra-red signal. An infra-red detector canreceive the data carried in the infra-red signal and appropriatecircuitry can place the data on bus 902. Bus 902 carries the data tomain memory 906, from which processor 904 retrieves and executes theinstructions. The instructions received by main memory 906 mayoptionally be stored on storage device 910 either before or afterexecution by processor 904.

Computer system 900 also includes a communication interface 918 coupledto bus 902. Communication interface 918 provides a two-way datacommunication coupling to a network link 920 that is connected to alocal network 922. For example, communication interface 918 may be anintegrated services digital network (ISDN) card, cable modem, satellitemodem, or a modem to provide a data communication connection to acorresponding type of telephone line. As another example, communicationinterface 918 may be a local area network (LAN) card to provide a datacommunication connection to a compatible LAN. Wireless links may also beimplemented. In any such implementation, communication interface 918sends and receives electrical, electromagnetic or optical signals thatcarry digital data streams representing various types of information.

Network link 920 typically provides data communication through one ormore networks to other data devices. For example, network link 920 mayprovide a connection through local network 922 to a host computer 924 orto data equipment operated by an Internet Service Provider (ISP) 926.ISP 926 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the“Internet” 928. Local network 922 and Internet 928 both use electrical,electromagnetic or optical signals that carry digital data streams. Thesignals through the various networks and the signals on network link 920and through communication interface 918, which carry the digital data toand from computer system 900, are example forms of transmission media.

Computer system 900 can send messages and receive data, includingprogram code, through the network(s), network link 920 and communicationinterface 918. In the Internet example, a server 930 might transmit arequested code for an application program through Internet 928, ISP 926,local network 922 and communication interface 918.

The received code may be executed by processor 904 as it is received,and/or stored in storage device 910, or other non-volatile storage forlater execution.

11.0 EXTENSIONS AND ALTERNATIVES

At this point, it should be noted that although the invention has beendescribed with reference to specific possible embodiments, it should notbe construed to be so limited. Various modifications may be made bythose of ordinary skill in the art with the benefit of this disclosurewithout departing from the spirit of the invention. Thus, the inventionshould not be limited by the specific possible embodiments used toillustrate it but only by the scope of the issued claims.

What is claimed is:
 1. A method comprising: causing a display of a firstprogram series recording schedule for a first digital video recorder(DVR) system, the first program series recording schedule including oneor more multimedia program series that is scheduled for the first DVR torecord on an ongoing basis; causing a display of a second program seriesrecording schedule for a second DVR system concurrently with the displayof the first program series recording schedule for the first DVR system;receiving input indicating selection of a multimedia program seriesrecording item in the first program series recording schedule for thefirst DVR system; adding the multimedia program series recording item tothe second program series recording schedule for the second DVR system;updating the display of the second program series recording schedule forthe second DVR system to include a display of the multimedia programseries recording item in the second recording schedule.
 2. The method ofclaim 1, further comprising: sending data representing the multimediaprogram series recording item to the second DVR system; receiving aconfirmation from the second DVR system that the multimedia programseries recording item has been added to a client-side instance of thesecond program series recording schedule, the client-side instance ofthe second program series recording schedule being stored on the secondDVR system.
 3. The method of claim 2, wherein the display of the secondprogram series recording schedule for the second DVR system is updatedto include the display of the multimedia program series recording itemin the second recording schedule in response to receiving theconfirmation from the second DVR system that the multimedia programseries recording item has been added to the client-side instance of thesecond program series recording schedule.
 4. The method of claim 1,further comprising: synchronizing a server-side instance of the secondprogram series recording schedule with a client-side instance of thesecond program series recording schedule resulting in adding themultimedia program series recording item in the client-side instance ofthe second program series recording schedule; wherein the client-sideinstance of the second program series recording schedule is a datacomponent of the second DVR system.
 5. The method of claim 1, furthercomprising: in response to receiving search criteria, searching aprogram guide to identify one or more multimedia programs that satisfythe search criteria.
 6. The method of claim 1, further comprising:establishing a network connection with the second DVR system and sendingdata representing the multimedia program series recording item to thesecond DVR system over the network connection.
 7. A non-transitorycomputer-readable medium storing instructions which, when executed byone or more computing devices, causes the one or more computing devicesto perform: causing a display of a first program series recordingschedule for a first digital video recorder (DVR) system, the firstprogram series recording schedule including one or more multimediaprogram series that is scheduled for the first DVR to record on anongoing basis; causing a display of a second program series recordingschedule for a second DVR system concurrently with the display of thefirst program series recording schedule for the first DVR system;receiving input indicating selection of a multimedia program seriesrecording item in the first program series recording schedule for thefirst DVR system; adding the multimedia program series recording item tothe second program series recording schedule for the second DVR system;updating the display of the second program series recording schedule forthe second DVR system to include a display of the multimedia programseries recording item in the second recording schedule.
 8. The medium ofclaim 7, wherein the instructions comprise further instructions which,when executed by one or more computing devices, causes the one or morecomputing devices to perform: sending data representing the multimediaprogram series recording item to the second DVR system; receiving aconfirmation from the second DVR system that the multimedia programseries recording item has been added to a client-side instance of thesecond program series recording schedule, the client-side instance ofthe second program series recording schedule being stored on the secondDVR system.
 9. The medium of claim 8, wherein the display of the secondprogram series recording schedule for the second DVR system is updatedto include the display of the multimedia program series recording itemin the second recording schedule in response to receiving theconfirmation from the second DVR system that the multimedia programseries recording item has been added to the client-side instance of thesecond program series recording schedule.
 10. The medium of claim 7,wherein the instructions comprise further instructions which, whenexecuted by one or more computing devices, causes the one or morecomputing devices to perform: synchronizing a server-side instance ofthe second program series recording schedule with a client-side instanceof the second program series recording schedule resulting in adding themultimedia program series recording item in the client-side instance ofthe second program series recording schedule; wherein the client-sideinstance of the second program series recording schedule is a datacomponent of the second DVR system.
 11. The medium of claim 7, whereinthe instructions comprise further instructions which, when executed byone or more computing devices, causes the one or more computing devicesto perform: in response to receiving search criteria, searching aprogram guide to identify one or more multimedia programs that satisfythe search criteria.
 12. The medium of claim 7, wherein the instructionscomprise further instructions which, when executed by one or morecomputing devices, causes the one or more computing devices to perform:establishing a network connection with the second DVR system and sendingdata representing the multimedia program series recording item to thesecond DVR system over the network connection.
 13. An apparatuscomprising: a device, at least in part implemented in hardware, thatcauses a display of a first program series recording schedule for afirst digital video recorder (DVR) system, the first program seriesrecording schedule including one or more multimedia program series thatis scheduled for the first DVR to record on an ongoing basis; a device,at least in part implemented in hardware, that causes a display of asecond program series recording schedule for a second DVR systemconcurrently with the display of the first program series recordingschedule for the first DVR system; a device, at least in partimplemented in hardware, that receives input indicating selection of amultimedia program series recording item in the first program seriesrecording schedule for the first DVR system; a device, at least in partimplemented in hardware, that adds the multimedia program seriesrecording item to the second program series recording schedule for thesecond DVR system; a device, at least in part implemented in hardware,that updates the display of the second program series recording schedulefor the second DVR system to include a display of the multimedia programseries recording item in the second recording schedule.
 14. Theapparatus of claim 13, further comprising: a device, at least in partimplemented in hardware, that sends data representing the multimediaprogram series recording item to the second DVR system; a device, atleast in part implemented in hardware, that receives a confirmation fromthe second DVR system that the multimedia program series recording itemhas been added to a client-side instance of the second program seriesrecording schedule, the client-side instance of the second programseries recording schedule being stored on the second DVR system.
 15. Theapparatus of claim 14, wherein the display of the second program seriesrecording schedule for the second DVR system is updated to include thedisplay of the multimedia program series recording item in the secondrecording schedule in response to receiving the confirmation from thesecond DVR system that the multimedia program series recording item hasbeen added to the client-side instance of the second program seriesrecording schedule.
 16. The apparatus of claim 13, further comprising: adevice, at least in part implemented in hardware, that synchronizes aserver-side instance of the second program series recording schedulewith a client-side instance of the second program series recordingschedule resulting in adding the multimedia program series recordingitem in the client-side instance of the second program series recordingschedule; wherein the client-side instance of the second program seriesrecording schedule is a data component of the second DVR system.
 17. Theapparatus of claim 13, further comprising: a device, at least in partimplemented in hardware, that, in response to receiving search criteria,searches a program guide to identify one or more multimedia programsthat satisfy the search criteria.
 18. The apparatus of claim 13, furthercomprising: a device, at least in part implemented in hardware, thatestablishes a network connection with the second DVR system and sendsdata representing the multimedia program series recording item to thesecond DVR system over the network connection.